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One of the most common ways of 
communicating between processes 
in a distributed system is the remote 
procedure call 1 This com munication device 
allows one process^ roj2al][ ITTiSctfen^ thai 
runs in some other .process, perhaps „ on ., a . ; 
dfffe^nUX^hiP^In tne traditional single- 
process programming model, control moves 
from one point in a program to another 
point in the same program. With RPC, how- 
ever, control can flow from a point in one 
program to a point in another program on 
another machine. 

The usual assumptions about RPC systems 
reflect the reality of most distributed envi- 
ronments. We generally assume, for exam- 
ple, that a machine making an RPC can 
know nothing about the architecture or the 
instruction set of the machine it is calling. 
Further, we generally assume (although not 
always, see the adjacent box) that the pro- 
gramming language used to implement the 
called program is also unknown. Most dis- 
tributed systems contain a variety of hard- 
ware, operating systems, and services — each 
implemented in the most convenient lan- 
guage — so these assumptions make sense. 

The Java language and platform 2 - 3 provide 
a base for distributed computing that 
changes several of these assumptions. In 
particular, the Java Virtual Machine allows a 
group of Java-enabled machines to be treat- 
ed as a homogeneous group rather than a 
heterogeneous group — despite possible dif- 
ferences in the machine architectures and 
underlying operating systems. Java also 
makes it possible to safely and dynamically 
load code in a running Java process. 
Together, these features allow a system to 
invoke methods on remote objects, which 
can move code associated with language- 
level objects from the calling process to the 
process called and vice versa. Combining 
these qualities with a languagercentric 



design not only significantly simplifies tra- 
ditional RPC systems, it adds functionality 
that was previously not possible. 

We designed Java Remote M etbgd 
Invocation (RMI) to support pure-Java dis- 
tributed objects in a seamless manner, 
allows calls to be made between Java objects 
in different virtual machines, even on differ- 
ent physical machines. RMI's language-cen- 
tric design allows distributed programming to 
take place entirely in Java, making available 
such language features as the Java type system 
and garbage collection. Coupled with the Java 
platform's code portability, RMI's language 
specificity greatly simplifies distributed object 
programming. In addition, the pure -Java 
approach enables RMI to support distributed 
polymorphism and pass-by-value objects in 
remote calls, features which traditional dis- 
tributed object systems cannot support. 

RMI's structure 

The RMI system consists of several basic, 
layers; a specific interface and protocol 
define the boundary at each layer. Each layer 
is independent of the next and can be 
replaced by an alternate implementation 
without affecting the other layers. For exam- 
ple, the current transport implementation in 
the Java Development Kit .1.1 is based on 
TCP (Transmission Control Protocol) using 
. Java sockets. However, a transport based on 
UDP (User Datagram Protocol) could be 
used as well. 

To accomplish transparent transmission of 
objects from one address space to another, 
the RMI system uses Java Object Serializa- 
tion. Another technique, which we call 
dynamic stub loading, supports client-side 
stubs that implement the same set of remote 
interfaces as a remote object itself. Because 
a _stu b_ supporting the exact set of remote 
types is available, to the client of a remote 
object, that client can use Java's built-in oper- 
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ators for casting and type checking remote objects. Tradi- 
tional, language-neutral distributed object systems cannot use 
built-in operators for casting and type checking, because they 
do not integrate distributed objects into any language's type 
system. 

Architectural overview 

The RMI system's layers consist of the following: 

• siu b/skeleton— client-side stubs (proxies) and server- 
^ side skeletons (dispatchers); 

• remote reference— reference and invocation behavior 
(for example, unicast and multicast); 

• transport — connection setup and management, remote 
object tracking; and 

• distributed garbage collection— reference-counting 
garbage collection of remote objects. 

RMI is a layer on top of the Java Virtual Machine, so it 
leverages the Java system's built-in garbage collection, secu- 
rity, and cJass-loading mechanisms. The application layer sits 
on top of the RMI system. 



Figure 1. RMI system architecture. 

Figure J shows the RMI system's layers. A remote method 
invocation from, a client to a remote server object travels 
down through the RMI system's layers to the client-side trans- 
port layer. Next, the client sends the invocation (potentially 
via a network communication) to the server-side transport. 
There, the invocation travels up through the server-side trans- 
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port layer to the server. The rest of this section summarizes 
the functionality at each of RMls layers. 

A client invoking a method on a remote server object actu- 
ally uses a stub (proxy) for the remote object as a conduit to 
that object. A client- held reference to a remote object, there- 
fore, is a reference to a local stub. This stub is an imple- 
mentation of the remote objects remote interfaces; it 
forwards invocation requests to that server object using the 
remote reference layer. 

This layer carries out the semantics of the type of invoca- 
tion. Each remote object implementation chooses its own 
invocation semantics. For example, the semantics can indi- 
cate that communication to the server is unicast (point-to- 
point), or that the server is part of a multicast group (to 
accomplish server replication). Thus, the RMI architecture 
provides a framework for adding new types of remote object 
communication in the future. 

The remote reference layer also handles reference seman- 
tics for the server. For example, the remote reference layer 
can handle live and/or persistent references to remote 
objects. A persistent reference allows objects that are not cur- 
rently servicing calls to be saved to a permanent store; this 



frees resources used by those objects. The next call to such 
an object reactivates it, returning it to the state it was in prior 
to being saved to persistent store. 

The transport layer is responsible for connection setup, 
connection management, and keeping track of and dis- 
patching to remote objects (the targets of remote calls) in 
the transports address space. To dispatch to a remote object, 
the transport forwards the remote call up to the remote ref- 
erence layer (specific to the server) . After performing any 
necessary server-side behavior, the remote reference layer 
hands off the request to the server-side skeleton. The skele- 
ton makes an up call to the remote object implementation, 
which carries out the actual method call. 

The return value of a call travels back through the skele- 
ton, remote reference layer, and transport on the server side, 
and then up through the transport, remote reference layer, 
and stub on the client side. Figure 2 shows the anatomy of 
an RMI call. In the figure, the remote object (obj) is repre- 
sented by the client-side stub for the remote object. This stub 
implements all the remote interfaces (and thus remote meth- 
ods of those interfaces) that the actual remote implementa- 
tion object supports. 
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Figure 2. Anatomy of a call. 



A call to "method" on stub "obj" 
marshals the arguments for the caJ) 
and sends the request to the host 
containing the remote object. The 
client-side transport initiates a con- 
nection to the remote virtual 
machine and sends a message 
encoding the RM1 call. 

The server-side transport receives 
the message, looks up the skeleton 
for the remote object, and dispatch- 
es the call to the skeleton. The skele- 
ton unmarshals the call's arguments 
and makes the up call to the actual 
remote object implementation. 
When the implementation completes 
its method by returning a result or 
throwing an exception, the skeleton 
marshals the result. Then, the trans- 
port sends the return result to the 
originating virtual machine. Finally. 

the stub initiating the call unmarshals the return result and 
either returns the value or throws the exception. 

What is not depicted in Figure 2 is the interaction of the 
stub with the remote reference layer. The stub interacts 
directly with the remote reference layer, not with the trans- 
port. Any call the stub initiates goes through the reference 
layer to ensure appropriate reference semantics. 

For example, if a remote reference included connection 
retry behavior, the remote reference would attempt a con- 
nection retry on behalf of the stub. When the connection 
was successful, the underlying transport for that reference 
type would take over, marshaling the arguments and send- 
ing the RMI call. 

Another kind of remote reference is one that carries out 
multicast to a set of replicas for a remote object. (RMI does 
not yet provide this behavior, but it will in the future.) The - 
stub for the remote object calls through the remote reference 
layer, which in turn communicates to the replica set via the 
transport. The reference layer provides the abstraction need- 
ed, so that multiple reference semantics can be carried out 
without a change to the stub's form. A stub simply instructs 
the layer beneath to initiate a call, marshal and unrnarshal 
parameters, and return results. Various behaviors can take 
place beneath the stub without necessitating a change to the 
stub itself. 

) . 
Object serialization 

The RMI system can pass parameters and return values 
either by reference or by value. If the object to be passed is 
itself a remote object, RMI passes a remote reference to that 
object. However, if the object is not a remote object, RMI 
passes a copy of the object to the receiver, thus giving the 
effect of pass-by-value. 

RMI uses Java Object Serialization to marshal and unrnar- 
shal parameters and return values. Object serialization pro* 
vides a simple, easy-to-use mechanism for accurately making 
copies of objects across time and space. It encodes objects 
from one virtual machine into a stream of bytes. The stream 
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can be passed through a network to another virtual machine 
or saved in a file or database for later retrieval. Later or else- 
where, object deserialization can construct copies of the orig- 
inal objects from the stream. 

Objects are likely to contain references to other objects, 
and the relationships between objects are integral to the 
meaning and function of each object. Object serialization tra- 
verses graphs of objects and maintains the relationships so ■ 
that the graph topology can be recreated. 

The default serialization mechanism makes it simple to 
save and restore objects. All that is needed is for the class to 
declare that it implements the java.lang.Serializable interface. 
This lets the system write or read the object, and does not 
require the class to implement any special methods to han- 
dle serialization. Only when the default behavior is not suf- 
ficient does the class implement methods to customize the 
fields and values written to and read from the stream. The 
class assumes control for writing and reading the stream's 
state by implementing methods for writes and reads. A typ- 
ical use of this function would be to write a more compact 
representation of a sparse data structure. 

ObjectOutputStream implements methods for writing 
objects to a stream. The writeObject method encodes the 
object using information in the virtual machine for the 
object's class and superclasses. Serialization iterates through 
each class from the highest serializable class down to the 
object's actual class. For each class, the method writes the 
nontransient and nonstatic public, protected, package, and 
private fields to the stream. For primitive types, it encodes the 
values in the stream. In addition, writeObject writes fields 
holding references to objects to the stream; these include 
arrays, strings, and classes. If the class has its own methods 
implemented for writeObject and readObject, these super- 
sede the default mechanism. 

ObjectlnputStream implements the complementary 
readObject method to read objects from a stream. Reading 
an object consists of reading its class, allocating a new 
instance, and restoring the contents for each of the object's 
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classes, from highest serializable class down to the actual 
class. The default deserialization reads values for primitive 
types from the stream and assigns them to fields. For object 
fields, a call to readObject reads the object from the stream. 
As each object is assigned to a field, object serialization 
checks that the object's type can be assigned to the field. 

Object graphs may be written to the stream; these are 
reconstructed with the same topology. Each ObjectOutput- 
Stream keeps a reference to each object written. The first 
time an object is written to the stream it is assigned a han- 
dle, and the handle remains with the reference to the object. 
When a new object is written, it is compared with the refer- 
ences for previously written objects. If the object already 
appears in the stream, it is encoded using the handle. Thus, 
each object is written to the stream exactly once, so all ref- 
erences to an object within the stream refer to the same 
instance. This naturally limits the graph traversal and assigns 
a unique number to each object within the stream. 

Essential to transporting the object accurately is identify- 
ing the object's actual type. The goal is to retain an object's 
semantics across serialization and deserialization. Classes are 
identified by name and signature, and the stream includes the 
class's supertypes as well. When objects are being read from 
the stream, the normal class -loading mechanisms retrieve 
the class and verify its signature. This signature is important 
confirmation that the same class has been found. When 
methods or fields are added to a class as it evolves, the sig- 
nature can be declared so that the class-loading mechanisms 
can identify the class as compatible with previous versions. 

The mechanisms for object serialization allow subclassing 
of the output and input streams for class annotation and 
object substitution. The overridable annotateClass method 
on the output stream is called for each class written to the 
stream. A subclass can insert additional information about 
the class into the stream. A corresponding resolveClass 
method is called as each class object is read from the stream; 
it reads the additional information and uses it to find the 
appropriate class. 

Before each object is serialized for the first time, the 
streams replaceObject method gives the stream a chance to 
examine and act on the object. A corresponding 
resolveObject method is called on the input stream after an 



object is read from the stream and before the object is 
returned. These callbacks to the stream allow suitable 
replacements of one object with another. The substituted 
objects are always type -checked before assignment, so sub- 
stitution does not compromise the objects' integrity. 

Passing by true type 

Because RMI uses object serialization to pass parameters 
and return values in RMI calls, it can pass the true type of an 
object from one virtual machine to another in a remote call. 
Thus, a remote method may define a formal parameter or 
return value as a specific Java type, but the remote call may 
pass a subtype of the declared type that preserves the object's 
true type on the receiving side. 

Traditional, language-neutral distributed object systems 
truncate the parameter or return value to the declared type 
in the remote method signature. With RMI, this is not the 
case. The ability to pass a complete object without changing 
its type is very important in object-oriented programs. RMI 
preserves the basic object-oriented notion of polymorphism. 
Any system that does not allow object polymorphism is not 
truly object-oriented, but simply object-based: 

In such (object-based) programs, types are generally 
viewed as static, whereas objects typically have a 
much more dynamic nature, which is somewhat con- 
strained by the existence of stafic binding and 
monomorphism. 4 

The RMI system does not constrain objects* "dynamic 
nature." 

Downloading code 

Remote procedure call systems must generate client-side 
stub code and link it into a client before making an RPC. 
This code can be either statically linked to the client or 
dynamically linked at runtime via libraries available locally 
or over a network file system. With either static or dynamic 
linking, the specific code that handles an RPC must be avail- 
able to the client machine in advance in compiled form. 

RMI generalizes this technique, using the Java system's 
dynamic class-loading mechanism at runtime to load (in 
Java's architecture -neutral bytecode format) the classes that 
handle method invocations on a remote object. The system 
downloads the following classes during an RMI call: 

• classes of remote objects and their interfaces; 

• stub and skeleton classes (created by the rmic stub com- 
piler) that serve as proxies for remote objects; and 

• other classes used directly in an RMI -based application, 
such as parameters to, or return values from, remote 
method invocations. 

In addition to class loaders, dynamic class loading employs 
two other mechanisms: the Java Object Serialization system 
to transmit class locations over the wire and a security man- 
ager to secure the classes loaded. 

As stated earlier, RMI uses object streams to transmit para- 
meters and return values for remote calls. RMI also places 
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additional information in the call 
stream to support dynamic code 
loading. Object serialization allows 
the RM1 runtime to annotate the 
stream with class-specific information 
when a class descriptor is written. 
RMI implements ObjectOutput- 
Stream's annotateClass method to 
write the code base URL at which the 
class can be downloaded. 

On the receiving end, RMI uses 
ObjectlnputStream's resolveClass 
method to read the code base URL 
embedded in the stream. If the class 
is not already defined locally, 
resolveClass then downloads the 
class from that location. Thus, a 
class's location (a URL) travels in the 
stream along with the objects of that 
class. 

A. class loaded by RMI is subject to 
the security restrictions put in place 
by the java.lang.SecurityManager 
installed for the virtual machine 
downloading that class. Browsers 

define an applet security manager for applets. This security 
manager prevents applets from accessing files on disk or 
opening network connections apart from those to the applet's 
host of origin; it also institutes other restrictions. For classes 
to be downloaded into applets or applications as a result of 
remote calls, RMI requires a security manager to protect the 
application and host from potential harm. 

Garbage collection and leasing 

In a distributed system, just as in a local system, it is desir- 
able to automatically delete remote objects that are no longer 
referenced by any client. Automatic garbage collection frees - 
the programmer from keeping track of remote objects' clients 
to determine when the program can terminate safely. RMI 
uses a reference-counting garbage collection algorithm sim- 
ilar to the one Birrell describes. 5 

To accomplish reference-counting garbage collection, the 
RMI runtime keeps track of all live remote references with- 
in each Java Virtual Machine. When a live reference enters 
a virtual machine, the runtime increments its reference count. 
Upon receiving the first reference to a specific remote object, 
t^ie client's RMI runtime sends a referenced (dirty) message 
to the remote object's RMI runtime. This way, a remote 
object's runtime keeps track of all clients that hold references 
to objects residing in its virtual machine. 

When a given virtual machine discovers a live reference 
to be unreferenced, the finalization of that reference decre- 
ments the count. When the client virtual machine has dis- 
carded the last reference to a specific remote object, the 
runtime sends an unreferenced (clean) message to the serv- 
er. Monotonically increasing sequence numbers maintain 
ordering among the dirty and clean calls. Interface 
java.rmi.dgc.DGC embodies the server side of RMI's distrib- 
uted garbage collector. 
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Figure 3. Stock notification service remote interfaces. These interfaces define 
those methods that can be called from another virtual machine. 



To handle client failure, the client holding a reference to 
a remote object leases the reference for a period.of time. The 
lease period starts when the remote object's runtime receives 
the dirty call. It is the client RMI runtime's responsibility to 
renew such leases before they expire; it does this by mak- 
ing additional dirty calls for the remote references it holds. ' 
If the client does not renew a lease before it expires, the dis- 
tributed garbage collector assumes that the client no longer 
references that remote object. 

RMI example 

In this section, we'll walk through an example of using 
RMI to implement a stock notification service. The complete 
code for this example is available as pan of the Java, 
Developer's Kit 1 . 1. The-example application consists of two 
basic remote objects: 

• a stock server that accepts requests from clients that wish 
to be notified when specific stocks are updated, and 

• an applet that participates both as a client of the stock 
service and as the entity notified when stocks are updat- 
ed (thus, the applet is also a server). 

The applet registers itself with the stock server for price 
updates of various stocks. The stock server keeps track of 
the remote objects requiring notification of stock updates, 
and sends periodic price updates to these remote objects 
.(implemented as applets). /The applet displays the stock 
prices in a graph that it updates dynamically as it receives 
stock information from the stock server. 

To write an applet or application using RMI, we first need 
to define the remote interfaces to the remote objects in our 
application. A remote interface is a Java interface that 
declares all the methods that may be invoked by clients of 
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Figure 4. The main( ) method to create and install the 
stock service. 
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figure 5. Impiementation of a remote method defined in 
the StockWatch interface. 



the remote object. Such clients make calls to remote inter- 
faces, not to the implementation classes of those interfaces.. 
RMI identifies remote interfaces as interfaces that extend the 
abstract interface java.rmi.Remote. 

The two remote interfaces of interest in the stock service 
application are StockWatch and StockNotify. The StockWatch 
interface is the interface to the stock server; the applet Jmple- , 
ments the StockNotify interface to be notified of stock price 
updates. (See Figure 3.) 

Remote objects in the RMI system must implement an inter- 
face that extends the java.rmi.Remote interface; both • 
StockWatch and StockNotify do this. Any method in. an inter- 
face that extends the java.rmi.Remote interface must declare 
that it may throw an exception of type RemoteException. This 
RMl-generated exception signals problems with communi- ' 
cation between the client and server of the particular call. 

Next, we implement the stock service as a simple remote 
object that supports unicast (point-to-point) reference seman- 
tics. The stock service directly implements the StockWatch 
remote interface. The simplest way to implement a server is 
to extend the Java. rmi.server.UnicastRemoteObject class, 
which provides simple point-to-point reference semantics. 
During construction, a UnicastRemoteObject makes itself 
available to the RMI runtime to accept requests from clients — 
that is, the object is "exported to the RMI runtime" when it 
is created. The StockServer constructor must include 
RemoteException in its "throws" clause, because during con- 
struction the object may encounter an error if it cannot be 
exported to the RMI runtime. 

public class Stockserver 

extends UnicastRemoteObject 
implements StockWatch, Runnable 

{ 

/** Construct the stock server */ 
public Stockserver ( ) throws 

RemoteException 

super(); 

/* initialize server data 

structures. - . */ 

) 

This segment shows the constructor for the StockServer; it 
also shows the beginning of the class definition of a class 
that will implement the StockWatch interface defined in 
Figure 3. 

To create the stock service and make it available to clients, 
StockServer's main method must do several things: create 
and install a security manager, create a StockServer remote 
object, and make the StockServer object available to clients 
via a name facility (see Figure 4) . 

First, the main method creates a security manager to pro- 
tect itself from code that may be downloaded during the RMI 
program execution. Some downloaded code cannot be trust- 
ed, so a SecurityManager provides a mechanism to "sandbox" 
the execution of downloaded code so that it cannot adverse- 
ly affect the local machine. RMI provides an example securi- 
ty manager, RMI SecurityManager, which implements security 
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policies similar to those provided by 
the security manager for applets run- 
ning in a browser. 6 

Next, the main method creates the 
StockServer remote object and 
installs it in a name facility. In this 
example, the server creates its own 
registry and uses that as a simple 
name facility. RMI provides a name 
registry that may be shared by all 
servers running on a host, but any 
specific server may create and use its 
own registry if desired. 

The call LocateRegistry.create 
Registry (2005) (see Figure 4) creates 
a registry on port 2005. The 
StockServer server object is bound in 
the registry via a call to Naming, 
rebind. The first argument in the 
rebind call is the URL (name) for the 
remote object. In the specified URL, 
the host defaults to the local host 
name, the port is specified as 2005, 
and the name is example.stock. 
StockServer. Note that the main 
method exits after these steps, but the 
server process remains alive as long 
as there are outstanding client refer- 
ences to the StockServer object. We 
ensure that the process remains alive 
by installing a reference to the remote 
object in the registry. (The system 
views the registry as a client, and so 
keeps the server process alive.) 

The implementation of the server 
is not quite finished; we must still 

implement all its remote methods. Figure 5 shows an imple- 
mentation of the watch method, which a client uses to request 
notification of stock price updates. The stock server adds the 
client (the StockNotify object) to its table (notifyTable) of 
remote objects to be notified of updates. A thread that sends 
periodic notifications to clients is started if the thread does not 
already exist. 

We now turn to the implementation of an applet that acts 
as a remote object to receive stock updates. StockApplet 
extends the Applet class and implements the StockNotify 
remote interface so that it can receive stock updates via the 
lipdate method. Since StockApplet extends the 
java.awt.Applet class, it cannot extend the java.rmi. serv- 
er. UnicastRemoteObject RMI server class to automatically 
make the remote object available to accept incoming calls. 

RMI provides another way to make a remote object avail- 
able to the RMI runtime so that the object may receive calls 
from clients (in this case, the client would be StockServer). 
By making an explicit call to the static method Unicast 
RemoteObject.exponObject(), an application or applet may 
export a specific remote object to the RMI runtime. Thus, in 
the applet's init method, the applet exports itself as a remote 
object to the RMI runtime. 
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Figure 6. Implementation of the applet init( ) method for an applet that makes a 
remote call to the stock server object defined in Figures 3 through 5. 
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Figure 7. Implementation of the applet's remote method 
update( ), called by the stock server. 
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RMI also allows objects to be 
passed by value. Traditional 
distributed systems do not 
allow pass-by-value objects 
because such objects imply that 
the code is available for the 
object on the receiving end. 



Next, the applet must register with the stock server to 
receive stock updates. This entails looking up the stock serv- 
er by name in its registry, and then invoking the stock serv- 
er's watch method for each stock. The name for the server 
is composed of the code base host (available via a call to 
base.getHostO). the registry's port (available via an applet 
parameter configured for this purpose) , and the name of the 
stock server, example.stock.StockServer. The applet uses the 
Naming.lookup method to look up the StockWatch remote 
object by name, then it invokes the watch method for each 
stock for which it needs updates. See Figure 6. 

In its role as a remote object, StockApplet implements the 
StockNotify interface, which consists of a single update 
method for receiving a stock price update. The. implemen- 
tation of this method simply stores the stock update infor- 
mation and repaints the graph to display the new 
information. See Figure 7. 

For this example, we have elided much of the code that 
deals with the specifics of storing and displaying the stock 
information. For details, see the full code in the RMI docu- 
mentation in the JDK 1.1 release. 

This example illustrates how to write a simple peer-to- 
peer distributed application using RMI. It does not fully 
demonstrate all of RMl's features, but it does show that build- 
ing an application in RMI is straightforward. 

One of RMI's strengths is that an object may be passed 
polymorphically in an RMI call. That is, subtypes of the 
declared parameter types of a remote method can be passed 
in a remote method call, and the code for the subtype is 
downloaded as a side effect of the call. 

Traditional distributed object systems do not allow para- 
meter polymorphism because they are language-neutral and 
cannot support downloading code. For example, in the 
example in Figure 7. the server only cared that it was com- 
municating with an object that implemented the StockNotify 
interface. However, the stub for the StockApplet that is 
passed to the StockServer supports the complete set of 
remote interfaces that the StockApplet supports. The 
StockServer could have discovered other remote interfaces 
that the StockNotify object implemented using standard Java 
language mechanisms (for example, instanceof). 

RMI also allows objects to be passed by value. Traditional 



distributed systems do not allow pass-by-value objects 
because such objects imply that the code is available for the . 
object on the receiving end. In multilanguage systems, code 
is not downloaded due to the system's heterogeneous nature. 
While it is theoretically possible to have a heterogeneous 
system. that downloads compiled code, such a system would 
require code compilation for all possible platforms, for all 
possible classes, as well as a static set of classes. 

We can give a powerful example of exploiting polymor- 
phism in RMI by defining a compute server interface that 
executes the run method for arbitrary Task objects: 

public interface Task implements 

Serializable { 

Ob j ect run ( ) ; 

> 

public interface ComputeServer extends 

j ava . rmi . Remote { 
Object runTask(Task task) throws 

j ava. rmi . Remote Except ion; 

) 

A client could define any object that implemented the non- 
remote Task interface and have its run method executed by 
a remote compute server. More specifically, it could send a 
task object to a ComputeServer in an RMI call; the task could 
be executed via a call to the task's run method, and the result 
could be returned to the caller. For example, 

public class FFT implements Task { 
public FFT<args..) {....}' 

public Object run() { 

// computes FFT and returns 

the result 

} 

> 

We could compute a fast Fourier transform (FFT) on a 
remote server simply by executing the following code: 



Such applications would be difficult if not impossible in tra- 
ditional distributed object systems. Since RMI downloads code, 
this application is not only possible, but an easy extension of 
the general programming patterns used in the language. 



IN JDK 1.1, RMI SUPPORTS a unicast reference type 
via the java.rrni.server.UnicastRemoteObjea class. In the future, 
we will add several features to RMI, including the following: 



ComputeServer . comp = 

( ComputeServer ) Naming . Lookup 

(" / /butterfly /computer") ; 
FFT fft = new FFT ( args . . . ) ; 
Object obj = comp.runTask(f f t) ; 
// display result returned in obj... 
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• support for persistent remote references that are valid 
from run to run of a server — that is, such references per- 
sist and are valid over time; 

• support for automatic server activation in conjunction 
with persistent remote references; 

• support for RMI over secure transports such as SSL 
and/or SKIP; 

• support for multicast remote references; and 

• performance enhancements. 

Beyond these enhancements to the basic RMI platform, 
we plan on using RMI's abilities to investigate other topics 
in the area of distributed systems. Since RMI allows systems 
to move code as well as data, and since it supports full poly- 
morphic typing, we believe it is a base for investigations into 
such areas as agent technology and just -in-time software 
distribution, pi 
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